A service provider, e.g. a web service provider, offers certain digital services typically to multiple potential clients, wherein these services are described for example in a web-service description language (WSDL), or in any other interface description language suitable for the type of services offered. The clients can find this description, e.g., by out-of-band transmission, from registries, or via web searches at the service provider. For many reasons, it might by desirable that the service provider associates policies with these services. In the context of this entire patent application, policies may be almost anything that the service provider wants to announce to its clients in addition to the pure service description, e.g., requirements that messages have to be encrypted or authenticated, requirements on certified attributes the client has to present, access-control policies that the service provider enforces, privacy policies that the service provider promises, compression algorithms that it understands, auditing that it promises, or quality of service that it offers. Sometimes the service provider may even only know internally that it has such requirements or follows privacy or audit policies. Such individual, domain-specific policies may be combined into an overall policy. In “Web Services Policy Framework (WS-Policy), F. Curbera et al., Version 1,0, Dec. 18, 2002, retrieved from
https://www.followed by:sdn.sap.com/content_documents/followed by:Web%20Services%20Policy%20Framework.pdf,current version, September 2004, retrieved fromftp://www6.software.ibm.followed by:com/software/developer/library/ws-policy.pdf,a web-services policy framework is described, in the following also referred to as “WS-Policy”. WS-Policy is a framework for combining arbitrary policies with operators such as “All” or “OneOrMore”. Most of the prior frameworks are specific for access control, i.e., Boolean decision policies, or combine policies according to an internal structure, e.g., they only combine different conditions or actions. The IETF Policy Core Information Model PCIM as specified in “Policy Core Information Model—Version 1 Specification”, B. Moore et al., Feb. 2001, retrieved from
http ://www.followed by:ietf.org/rfc/rfc3060.txt, and in “Policy Core InformationModel (PCIM) Extensions”, B. Moore, January 2003,retrieved fromhttp://www.followed by:ietf.org/rfc/rfc3460.txt describes such a policy frameworkfor an internal structure.
The association of policies with services, i.e., describing which policy applies to which service, can have a policy-external part, saying “for these services, the following policies are applicable”, and a policy-internal part, saying “apply this policy only if one of the following sub-services is called” or “apply this policy only if the called sub-service fulfils the following condition”. At least a rudimentary policy-external part is always recommended because one cannot look all over the world which policies internally say that they apply to a certain service. For WS-Policy, fine-grained policy-external association was chosen and specified in the standards proposal “Web Services Policy Attachment (WS-PolicyAttachment)”, F. Curbera et al., Version 1,0, Dec. 18, 2002, retrieved from
https://www.followed by:sdn.sap.com/content_documents/followed by:Web%20Services%20Policy%20Attachment.pdgcurrent version, September 2004 fromftp://www6.software.followed by:ibm.com/software/developer/library/ws-polat.pdf,also referred to as the “WS-PolicyAttachment”. In contrast,PCIM largely chose an internal association approach bypolicy conditions.
The WS-PolicyAttachment leads to the impression that given an incoming message there is exactly one applicable policy, determined by the exact sub-service that this message addresses: For WSDL as the service definition language, WS-PolicyAttachment makes this fine-grained association by associating (“attaching”) polices with service-structuring elements like WSDL portTypes, ports, operations, and input messages. Within WS-PolicyAttachment it is defined how policies are inherited along these service-structuring elements of an overall WSDL definition, which essentially form a hierarchy, i.e., a tree-like structure where children nodes correspond to subsets of sub-services, and are merged into one applicable policy for each finest sub-service, called “effective policy”. Thus, as long as one does not attach different policies to two WSDL definition files of the same service, the applicable policy for each incoming message should be uniquely defined. Having just one applicable policy for each incoming message is a very useful feature, because then all preferences or orders among the sub-policies can be determined by the operators of WS-Policy and their semantics, while otherwise they are undefined. PCIM might however lead to undefined situations in cases where multiple policies apply and describe message transformations or state changes, not just Boolean expressions.
The common way to associate policies with services is to associate them with the service structure as WS-PolicyAttachment does. The idea is that every incoming message is addressed to a particular sub-service, and the recipient looks up the policy for this sub-service and applies it to the message. However, it has not yet been addressed how the association of a policy can be achieved for transformational policies, such as encryption and compression. These policies transform the message such that the service-level addressing element (e.g., in terms of WSDL operations) is not visible in the incoming message.
Consequently, it is desired to provide a method and a corresponding computing device for determining an applicable policy for an incoming message which enables to determine the applicable policy also if the incoming message comprising the service-level addressing element is transformed, for example by encryption or by data compression.